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ABSTRACT 



A layer two forwarding protocol (L2F) provides virtual 
direct dial-up service into private networks through public 
internet service providers. An authorized remote client 
appears as a direct dial-up client to the home gateway, even 
through the client is accessing the home gateway remotely 
through the ISP. The new forwarding protocol allows the 
remote client to conduct point-to-point link protocols, such 
as point-to-point protocol (PPP) and serial line interface 
protocol (SLIP) directly with the local network home gate- 
way. The network access server changes from a routing 
mode where a communication protocol is conducted with 
the client to a switching mode where the POP simply sends 
data from one port to a runnel. The tunnel then transmits the 
data to another port, regardless of the header information on 
transmitted data packets. The remote client can then be 
managed through databases controlled by the local network 
and gain access to resources not typically accessible through 
the internet. The layer two forwarding protocol conducts an 
independent authorization session to prevent unauthorized 
access to the private network and provides point-to-point 
protocol transport over the internet independently of internet 
transport protocols. 

21 Claims, 7 Drawing Sheets 




09/13/2004, EAST version: 1.4.1 



US 6,308,213 Bl 

Page 2 



U.S. PATENT DOCUMENTS 



5,437,013 * 7/1995 Rubin 709/230 

5,602,918 ♦ 2/1997 Chen et al 713/153 

5,604,803 * 2/1997 Aziz 709/228 

5,623,605 ♦ 4/1997 Keshav et al 709/235 

5,631,897 ♦ 5/1997 Pacheco et al 370/237 

5,642,515 * 6/1997 Jones et al 709/227 

5,689,566 * 11/1997 Nguyen 713/155 

5,715,399 * 2/1998 Bezos 705/27 

5,717,690 * 2/1998 Peirce, Jr. et al 370/389 

5,740,371 * 4/1998 Wallis 709/229 



5,745,708 * 4/1998 Weppler et al 710/119 

5,802,290 * 9/1998 Casselman 709/201 

5,918,019 * 6/1999 Valencia 709/227 

OTHER PUBLICATIONS 

D. Mathieson, C Kalbfleisch, S. Hunt, and K. Low, "High 
Speed Serial Communications for Control System," IEEE, 
pp. 1826-28. 

Article authored by Kevin Fogarty and Tim Greene entitled 
"Microsoft runnels through the Net with new protocol." 

* cited by examiner 



09/13/2004, EAST version: 1.4.1 




09/13/2004, EAST version: 1.4.1 



U.S. Patent 



Oct. 23, 2001 



Sheet 2 of 7 



US 6,308,213 Bl 



CM' 





CM 


-Jl- 















CM 



<o 

Oh 



o 



0.5-iLdir 



CM' 



y <t/i 



CO 
CM' 



Ouj 
LU -J 



o 

CM' 

co 

CM 




FIREWALL 



CN 

u 

LI- 




co 



CO 



O 

<0< 0 2 



eg' 



V AL U 



CM 



UJ 



■uJO a 



o ^ ui 9; 



CO 
CM' 



LJj- 

























Q_oa:i— co 



'CM 



to 



CN 



09/13/2004, EAST Version: 1.4.1 



U.S. Patent 



Oct. 23, 2001 Sheet 3 of 7 



US 6,308,213 Bl 




09/13/2004, EAST version: 1.4.1 



U.S. Patent Oct. 23, 2001 Sheet 4 of 7 US 6,308,213 



RECEIVE PPP 
DIAL-UP SESSION 



NEGOTIATE LCP 



AUTHENTICATE 
CLIENT 



48 



MAP USER NAME 



STANDARD 
INTERNET 
SERVICE 



NO 




INITIATE TUNNEL 
CONNECTION 



ALLOCATE 
MULTIPLEX ID 



SEND SETUP 
NOTIFICATION TO 
HOME GATEWAY 



58 

i 



56 



DISCONNECT 


NO 


CALL 





FIG.4 



HOME 

GATEWAY 

ACCEPT 

CONN. 
? 

"yes 



CONNECT CALL 



•40 



41 



•42 



•44 



•50 



•52 



•54 



ESTABLISH VIRTUAL 
DIAL-UP SESS ION 



RECEIVE/TRANSMIT 
LINK LEVEL FRAMES 



60 

■61 

63 



09/13/2004, EAST version: 1.4.1 



U.S. Patent Oct. 23, 2001 



Sheet 5 of 7 US 6,308,213 Bl 



AUTHENTICATION^ 



SET-UP 
NOTIFICATION 
PACKET 



L2F HEADER 



CHALLENGE, 
USER NAME, 

CHALLENGE 
RESPONSE 



LCP 



62 



■64 



65 



•66 



FIG.5 



RECEIVE SET-UP 
NOTIFICATION 



72 



76 

A. 



DISCONNECT 
CALL 




ACCEPT TUNNEL 
CONNECTION 



I 



ESTABLISH VIRTUAL 
DIAL-UP SESSION 



I 



RECEIVE /TRANSMIT 
LINK LEVEL FRAMES 



78 



80 



82 



FIG.6 



09/13/2004, EAST Version: 1.4.1 



U.S. Patent Oct. 23, 2001 Sheet 6 of 7 US 6,308,213 



RECEIVE 
INCOMING 
FRAME 



83 



FROM 
REMOTE 
CLIENT 



STRIP SOME 
PHYSICAL MEDIA 
ENCODING 



I 



ENCAPSULATE 
IN L2F 



FORWARD TO 
APPROPRIATE 
TUNNEL 

(return) 




FROM 
HOME 
GATEWAY 



— 86 



— 88 



•90 



FIG.7 



1 



STRIP L2F 



■92 



TRANSMIT 
TO REMOTE 
CLIENT 



— 94 



(return) 



09/13/2004, EAST Version: 1.4.1 



U.S. Patent 



Oct. 23, 2001 



Sheet 7 of 7 



US 6,308,213 Bl 





GO 

u 

LL 



u 
o 
z 
u 

o 

Ixl 

CO 



o 
o 
o 

o 
cr 

Q_ 



Ld 

> 



o 
o 
O 
o 
o 
o 
o 



CO 

a. 



z 
u 

I— I 

_1 
o 



X 
UJ 

—I 

CL 
•— i 
t- 

_1 
ID 



_J 
< 



a. 
o 



CO 
Lu 
Lu 

o 



h- 

o 
z 

Ixl 



< 

z 
o 

H 

GL 
O 

> 
Ld 



< 
O 
_l 
>- 
< 
CL 



< 
z 
o 



CL 

o 



3 

O 
Ixl 
X 

o 



CM 
rO' 



Ixl -J 



09/13/2004, EAST Version: 1.4.1 



US 6,308 ; 

1 

VIRTUAL DIAL-UP PROTOCOL FOR 
NETWORK COMMUNICATION 

CO-PENDING APPLICATIONS 

This application is a continuation of application Ser. No. 5 
08/687,973 filed Jul. 29, 1996 now U.S. Pat. No. 5,918,019 
and U.S. Provisional patent application Ser. No. 60/034,508 
filed Dec. 27, 1996. 

BACKGROUND OF THE INVENTION 

10 

This invention relates generally to network systems and 
more particularly to a virtual dial-up system used for access- 
ing a private local network through an internet access 
service. 

FIG. 1 is a prior art internetwork system 12 which 35 
includes multiple dial-up network access servers (NAS) 14 
also referred to as points of presence (POPs). The POPs 14 
can be located at different geographical locations around the 
world. An internet service provider (ISP) operates multiple 
POPs 14 through a backbone network 16. The ISP network 2 q 
16 is connected to an internet infrastructure, referred to 
generally as internet 18. Different clients 26 dial into a POP 
14 in order to access the internet through the ISP network 16. 

Local Area Networks (LANs) 22 are typically operated by 
. private companies and include multiple local clients 26. The 2 5 
LAN 22 is connected to internet 18 through a home gateway 
20. The home gateway 20 includes a firewall 28 that 
prevents unauthorized external access into the private net- 
work 22 through internet 18. While some access is possible 
from outside the firewall (e.g., electronic mail), resources 30 
such as network databases and application programs are 
only accessible by clients located behind the firewall 28. 

An authorized client may need to access files and other 
resources on network 22 from remote locations, such as 
when working at home or while on sales trips. Privately 35 
operated POPs 24 provide the remote clients with a direct 
dial-up capability to network 22. Since the POP 24 is located 
behind firewall 28, a remote client can dial into POP 24 and 
gain full access to resources on network 22. 

In many instances, it is more cost effective for companies 40 
to outsource dial-up service to general internet service 
providers, such as ISP 16. However, the firewall 28 in home 
gateway 20 denies access to remote clients that attempt to 
access LAN 22 through a general internet service provider. 

Different network protocols may be used within the 4 5 
internet infrastructure and within the private network 22. For 
example, an Internet Protocol (IP) is typically used at the 
network protocol level to send information through the 
internet 18. However, private networks 22 may use any one 
of a variety of network protocols including IP, IPX, 50 
Appletalk, etc. When a remote client dials into a POP 14, the 
ISP dynamically assigns an IP address to the remote client 
26. Thus, the remote client may be denied access by home 
gateway 20 because the IP address assigned by the ISP 
network 16 is not one of the authorized addresses in the 55 
LAN 22. The remote client may also be forced by the ISP to 
use an IP protocol incompatible with the local network 22. 
Because the IP protocol and the local LAN protocol are 
incompatible, the remote client is prevented from accessing 
resources on LAN 22. 60 

Accordingly, a need remains for remote client access to 
private networks through internet service providers while 
maintaining security from unauthorized internet users. 

SUMMARY OF THE INVENTION 65 

A layer two forwarding protocol (L2F) is integrated with 
existing network protocols to provide a virtual direct dial-up 
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service into private networks from internet service provid- 
ers. A remote client accesses an ISP network access server 
(NAS). The NAS determines whether the remote client is 
requesting virtual dial-up service to a local network or 
standard dial-up service. If virtual dial-up service is 
requested, a tunnel connection is established from the NAS 
to a home gateway for the local network. If the home 
gateway acknowledges the remote client as an authorized 
network user, a direct dial-up session is established between 
the NAS and the home gateway. 

The L2F allows the remote client to negotiate with the 
home gateway using a point-to-point link level protocol such 
as point-to-point protocol (PPP). The remote client can then 
be managed through databases controlled by the local net- 
work and gain access to resources not typically accessible 
through the internet. Thus, the remote client appears as a 
direct dial-up client to the home gateway, even through the 
client is accessing the home gateway remotely through the 
ISP. 

A PPP user uses various link level protocols such as link 
control protocol (LCP) and network control protocol (NCP) 
to initially negotiate bidirectionally between the remote 
client and the NAS. PPP negotiates physical parameters 
between the remote client and the POP. For PPP, an authen- 
tication protocol such as a challenge and authorization 
protocol (CHAP) or a password authentication protocol 
(PAP) is used to verify the remote client identity. During the 
authentication process, the remote client encrypts a random 
number based on a remote client password which cannot be 
authenticated by the NAS. Thus, if the remote client dials up 
to the wrong location and the client responds, the dial-up 
server will not receive any password information that can be 
used for unauthorized access to the local network. 

The NAS looks at the remote client name to determine a 
communication destination and requirements for establish- 
ing a tunnel connection with the home gateway. The NAS 
uses L2F to authenticate the remote client with the home 
gateway. The home gateway looks through a local database 
for the client name and an associated client password. The 
private system then independently encrypts a random num- 
ber transmitted from the NAS according to the client pass- 
word. If the random number encrypted by the home gateway 
matches the random number encrypted by the remote client, 
a tunnel connection is established between the NAS and the 
home gateway. 

If the tunnel connection is established, the NAS is essen- 
tially converted from a PPP endpoint into a switch. In other 
words, the NAS changes from a routing mode where a 
communication protocol is conducted with the client to a 
switching mode where the POP simply sends data from one 
port to a tunnel. The tunnel then transmits the data to another 
port, regardless of the header information on transmitted 
data packets. 

L2F tunnels at the link level frames (i.e., HDLC and async 
HDLC) of higher level protocols. By using runnels, it is 
possible to divorce the location of the initial dial-up server 
from the location where the dial-up protocol connection is 
terminated and access to the network is provided. The PPP 
session can then be projected from the NAS to the home 
gateway appearing to the home gateway as a direct dial-up 
session. LCP occurs between the client and the NAS for 
establishing subsequent protocols used between the remote 
client and the local LAN. For example, an IP control 
protocol (IPCP) can be negotiated to establish communica- 
tion between the internet and an Appletalk protocol (ATPT). 

L2F provides the ability to multiplex multiple clients 
within a tunnel and allows the home gateway to tell different 
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tunnels apart. From a L2F header, the home gateway deter- 
mines what NAS and client the data is coming from and 
accordingly connects the client to the correct virtual inter- 
face. The tunneling technique used in conjunction with L2F 
does not require authentication or address assignment from 5 
the ISP. Thus, termination protocols and updating require- 
ments normally performed by the ISP, and which are incom- 
patible with private networks such as IPX and Appletalk, are 
not necessary. 

L2F allows multiple protocols and unregistered IP 30 
addresses to be used across existing internet infrastructure. 
Thus, very large investments in access and core infrastruc- 
ture can be shared. 

The foregoing and other objects, features and advantages 
of the invention will become more readily apparent from the 15 
following detailed description of a preferred embodiment of 
the invention which proceeds with reference to the accom- 
panying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 20 

FIG. 1 is a prior art diagram of an internet system. 

FIG. 2 is a diagram showing a virtual dial-up session 
according to the invention. 

FIG. 3 is a diagram showing different phases of the virtual 25 
dial-up session. 

FIG. 4 is a step diagram showing steps performed by the 
network access server when establishing a virtual dial-up 
session. 

* 30 

FIG. 5 is a diagram showing a data structure for a layer 
two forwarding protocol set-up notification packet. 

FIG. 6 is a step diagram showing steps performed by a 
home gateway when establishing the virtual dial-up session. 

FIG. 7 is a step diagram showing operation of the network 35 
access server during the virtual dial-up session. 

FIG. 8 is a diagram showing the authentication protocol 
conducted during a forwarding protocol session. 

FIG. 9 is a diagram of the data structure for the layer two 
forwarding protocol. 40 

DETAILED DESCRIPTION 

Referring to FIG. 2, remote client 26 is coupled to an 
Internet Service Provider (ISP) network access server (NAS) 45 
27 that accesses the internet infrastructure 18 via a Public 
Switched Telephone Network (PSTN) 30 (i.e., async PPP via 
modems). Remote client 32 is coupled to a NAS 27 through 
a port and accesses the internet 18 via an Integrated Services 
Digital Network (ISDN) 36 (i.e., synchronous PPP access). 50 
A private Local Area Network (LAN) 22 includes local 
clients 23 and is connected to internet 18 through a home 
gateway 20 which includes a firewall 28. NAS 27 is alter- 
natively defined as an ISP Point of Presence (POP). 

The hardware and software required to generally operate 55 
NAS 27, PSTN 30, ISDN 36, internet infrastructure 18, 
home gateway 20, firewall 28 and local clients 26 and 
remote clients 26 and 32 are all well known to those skilled 
in the art and are, therefore, not described in detail. 

Remote client 32 accesses LAN 22 through a virtual 60 
dial-up session according to the invention. During the virtual 
dial-up session, the remote client 32 appears as a direct 
dial-up client to home gateway 20. Thus, remote client 32 
can access any of the resources, such as local clients 23, on 
LAN 22 through the internet service provider NAS 27. Since 65 
the remote client 32 can access resources from NAS 27, the 
company operating LAN 22 is not required to purchase and 
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maintain private POPs 24 (FIG. 1). Because remote client 32 
can utilize a local NAS, long distance calls do not have to 
be made to a dial-up server located at LAN 22. 

The virtual dial-up session uses the L2F protocol to 
project a point-to-point link level session (e.g., PPP/SUP 
34) from the NAS 27 to home gateway 20 (e.g., PPP/SUP) 
35. The PPP/SLIP session 34 is encapsulated in L2F 29 and 
then transmitted from NAS 27, through internet 18, to home 
gateway 20. The home gateway uses the L2F protocol 29 to 
verify that remote client 32 is an authorized user for LAN 22 
and to establish a tunnel 33 between NAS 27 and home 
gateway 20. After verification and tunnel establishment, L2F 
29 is used to conduct a direct link level session, such as LCP, 
between remote client 32 and home gateway 20. 

Referring to FIG. 3, the remote client 32 in one 
embodiment, comprises a personal computer having a 
processor, memory and a modem. The remote client 32 
initially dials up a local telephone number for dialing into 
NAS 27. NAS 27 includes a processor, memory and a 
modem for receiving and processing data transmitted from 
the remote client 32. In order to establish communications 
over the point-to-point link between remote client 32 and 
NAS 27, each end of the PPP link must first send LCP 
packets to configure and test the data link. 

The NAS 27 uses a modem or a router (not shown) to 
connect into internet 18. Software in NAS 27 encapsulates 
the PPP session in L2F. Using existing protocols, such as 
User Datagram Protocol (UDP) and Internet Protocol (IP), 
NAS 27 creates the tunnel 33 through the internet 18 that 
carries the L2F packet to gateway 20. The home gateway 20 
includes a processor, memory and a modem that connects to 
internet 18. A two step authentication protocol is then 
conducted. The NAS 27 and the home gateway 20 first 
perform a bidirectional authentication and then the remote 
client 32 authenticates. If the remote client 32 is authenti- 
cated as an authorized client for LAN 22, a tunnel connec- 
tion is made between NAS 27 and home gateway 20 and the 
virtual dial-up session is established. The L2F encapsulated 
PPP packet is then tunneled from NAS 27 to home gateway 
20. 

Remote client 32 and home gateway 20 are then free to 
negotiate NCPs for each protocol. After the PPP session 
between remote client 32 and home gateway 20 is estab- 
lished via tunnel 33, remote client 32 is free to access 
resources in LAN 22 without restrictions from the firewall 
28 in home gateway 20 (FIG. 2) or from incompatible 
network protocols. 

Remote Client/NAS Point-to-Point Protocol Session 

FIG. 4 is a step diagram describing the initial dial-up 
session between remote client 32 and NAS 27. The remote 
client 32 initiates a PPP connection 34 (FIG. 2) to NAS 27 
in step 40. The NAS 27 accepts the connection and the PPP 
link is established. LCP is negotiated in step 41. 

The NAS 27 authenticates the client 32 using an authen- 
tication protocol such as CHAP in step 42. The NAS 27 
pursues authentication to the extent required to discover the 
remote client's apparent identity, and by implication, the 
desired home gateway 20. Point-to-point protocols such as 
PPP/SLIP and authentication protocols, such as CHAP, are 
well-known to those skilled in the art and are, therefore, not 
explained in detail. 

A username field is interpreted by NAS 27 in step 44 to 
determine whether virtual dial-up service is required. The 
username is either structured (e.g., bill@localnet.com) or the 
NAS 27 maintains a database mapping users to services. In 
the case of virtual dial-up, the mapping will name a specific 
endpoint, the home gateway 20. If a virtual dial-up service 
is not required, standard access to the internet 18 is provided 
in step 48. 
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When step 46 determines a virtual dial-up is requested 
(i.e., the apparent remote client identity is determined), step 
50 initiates a tunnel connection to the home gateway 20 
using the authentication information gathered by the NAS 
27 in step 42. If a tunnel 33 is already initiated between the 
NAS 27 and home gateway 20, a slot in the tunnel 33 is 
allocated for the remote client 32. Tunneling is provided by 
an existing protocol such as (UDP), Frame Relay permanent 
virtual connections (PVCs), or X.25 virtual connections 
described in detail in the following request for comments 
(RFCs) UDP-RFC 768, IP=RFC 791, Frame Relay-RFC 
1490. 

Once the tunnel 33 exists, an unused multiplex ID (MID) 
is allocated, in step 52 and a set-up notification packet (see 
FIG. 5) is sent to notify the home gateway 20 of the new 
dial-up session. The NAS 27 waits for the home gateway 20 
either to accept or reject the set-up notification in step 56. 
Rejection can include a reason indication, which is dis- 
played to the remote client 32. After the rejection is 
displayed, the call from NAS 27 to home gateway 20 is 
disconnected in step 58. If the set-up notification is accepted, 
step 60 connects the call and step 61 establishes the virtual 
dial-up session in step 61. Link level frames are then 
received and transmitted between the two endpoints in step 
63. 

Referring to FIG. 5, a set-up notification packet 62 
includes a L2F header 64, authentication data 65. and LCP 
data 66. The packet 62 is used by the home gateway 20 to 
authenticate the remote client and to decide whether to 
accept or decline the tunnel connection. In the case of 
CHAP, the set-up notification packet authentication data 
includes a random number challenge, username and pass- 
word. For PAP or text dialog (i.e., for SLIP users), the 
authentication information 65 includes username and clear 
text password. The home gateway 20 can use this informa- 
tion to complete remote client authentication, avoiding an 
additional cycle of authentication. 

To initiate a PPP session between the remote client 32 and 
the home gateway 20, the set-up notification packet 62 
includes a copy of LCP parameters 66 for the completed 
LCP negotiation between remote client 32 and NAS 27 
(FIG. 3). The home gateway 20 may use this information to 
initialize its own PPP state avoiding additional LCP nego- 
tiation. The home gateway 20 may alternatively choose to 
initiate a new LCP exchange with remote client 32. 

Referring to FIG. 6, the home gateway 20 receives the 
set-up notification packet 62 sent from the NAS 27 in step 
72. The home gateway 20 conducts remote client authori- 
zation in decision step 74. If the client is not in the home 
gateway 20 local database (FIG. 3), the tunnel slot between 
NAS 27 and home gateway 20 is disconnected in step 76. If 
the remote client is validated as an authorized user, home 
gateway 20 accepts the tunnel connection in step 78. A 
"virtual interface" is established for SLIP or PPP in step 80. 
The virtual interface is established in a manner analogous to 
a direct-dialed connection. With the "virtual interface" in 
place, link level frames are passed over the tunnel in both 
directions in step 82. 

Referring to FIG. 7, after the virtual dial-up session is 
established, frames are received at the NAS 27 in step 83. If 
NAS 27 receives information from remote client 32, the 
frames are stripped of any link framing or transparency bits 
or bytes (physical media encoding) in step 86, encapsulated 
in L2F in step 88, and forwarded over the appropriate tunnel 
slot to home gateway 20 in step 90. The home gateway 20 
accepts these frames, strips L2F, and processes them as 
normal incoming frames for the appropriate interface and 
protocol. 
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The home gateway 20 encapsulates packets sent to NAS 
27 in L2F. In step 82, the NAS 27 determines the data is 
coming from the tunnel slot connected to the home gateway 
20. The frame is stripped of L2F in step 92 and transmitted 
5 out its physical interface (e.g., modem) to the remote client 
32 in step 94. 

The connectivity between remote client 32 and home 
gateway 20 is a point-to-point PPP or SLIP connection 
whose endpoints are the remote client's networking appli- 
cation on one end and the termination of this connectivity 

1 into the home gateway's SUP or PPP virtual interface on the 
other end. Because the remote client becomes a direct 
dial-up client of the home gateway access server, client 
connectivity can now be managed by the home gateway 20 
with respect to further authorization, protocol access, and 

15 filtering. Accounting can be performed at both the NAS 27 
as well as the home gateway 20. 

Because the L2F set-up notification packet 62 for PPP 
remote clients contain sufficient information for the home 
gateway 20 to authenticate and initialize an LCP state 

20 machine 23, it is not required that the remote client 32 be 
queried a second time for CHAP authentication, nor that the 
client undergo multiple rounds of LCP negotiation and 
convergence. Thus, connection set-up between the remote 
client 32 and home gateway 20 is optimized and transparent. 

25 Addressing 

There are several significant differences between standard 
internet access service and the virtual dial-up service with 
respect to authentication, address allocation, authorization 
and accounting. The mechanisms used for virtual dial-up 
service coexist with the internet protocol's traditional 
mechanisms and allow the NAS 27 to simultaneously ser- 
vice standard ISP clients as well as virtual dial-up clients. 

For an internet service, an IP address may be allocated to 
the remote client dynamically from a pool of service pro- 
vider addresses. Thus, the remote user has little or no access 

35 to their home network's resources, due to firewalls and other 
security policies applied by the home network to accesses 
from external IP addresses. 

For L2F virtual dial-up, the home gateway 20 exists 
behind the home firewall and allocates addresses which are 

40 internal to the home LAN 22, such as non-IP addresses. 
Because L2F is tunneled exclusively at the frame level, the 
policies of such address management protocols are irrel- 
evant for correct virtual dial-up service; for all purposes of 
PPP or SLIP protocol handling, the dial-up user appears to 

45 have connected at the home gateway 20. 
Remote Client Authentication 

The authentication of the remote client occurs in three 
phases; the first authentication phase occurs at the ISP, and 
the second and optional third authentication phase occurs at 

50 the home gateway 20. 

The ISP uses the username to determine that a virtual 
dial-up service is required and initiates the tunnel connection 
to the appropriate home gateway 20. Once a tunnel is 
established, a new multiplex ID is allocated and a session 

55 initiated by forwarding the gathered authentication informa- 
tion. 

The home gateway 20 undertakes the second phase by 
deciding whether or not to accept the connection. The 
connection indication may include CHAP, PAP, or textual 

60 authentication information. Based on this information, the 
home gateway 20 may accept the connection, or may reject 
it (for instance, it was a PAP request and the username/ 
password are found to be incorrect). Once the connection is 
accepted, the home gateway 20 is free to pursue a third phase 

65 of authentication at the PPP or SLIP level such as proprietary 
PPP extensions, or textual challenges carried via a TCP/IP 
telnet session. 
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FIG. 8 is a diagram showing the authorization steps 
conducted while establishing a virtual dial-up session. In 
step 1, various link level protocols such as LCP are used to 
initially negotiate bidirectionally between the remote client 
32 and the NAS 27. In step 2, a challenge such as CHAP is 
transmitted from NAS 27 to the remote client 32. During the 
challenge, the NAS 27 sends a random number (R) to remote 
client 32. 

In step 3, the remote client encrypts the random number 
R based on a remote client password (pwd). The password 
is a shared secret between remote client 32 and home 
gateway 20. The encrypted password cannot be authenti- 
cated by the NAS 27. Thus, if the remote client 32 dials up 
to the wrong location and responds, the dial-up server will 
not receive any password information that can be used for 
unauthorized access to the local network. The encryption of 
R according to the password (C(R)pwd) is conducted using 
an existing encryption algorithm such as CHAP which is 
known to those skilled in the art. The remote client name, 
and the encrypted random number are transmitted back to 
NAS 27. 

In step 4, based on the remote client name, the NAS 32 
establishes a tunnel to home gateway 20. The NAS 32 
transmits the remote client name, the random number, the 
encrypted random number C(R)pwd and the LCP session 
through the tunnel to the home gateway 20. The home 
gateway 20 then independently encrypts the random number 
R according to the client password which is prestored in the 
home gateway database. If the random number encrypted by 
the home gateway 20 matches the random number encrypted 
by the remote client 32, a virtual interface is established 
between the NAS 27 and the home gateway 20. An optional 
authorization step 5 can be conducted in a PPP session 
between remote client 32 and home gateway 20. 
Accounting 

The home gateway 20 can decline a connection based on 
the authentication information collected by the NAS 27. 
Accounting can easily draw a distinction between a series of 
failed connection attempts and a series of brief successful 
connections. Because authentication is conducted before 
allowing the tunnel connection, spurious connection costs 
will be prevented by remote clients failing the authentication 
session. 

Since virtual dial-up is an access service, accounting of 
connection attempts (in particular, failed connection 
attempts) is important. The home gateway 20 can accept 
new connections based on the authentication information 
gathered by the NAS 27 with corresponding logging. For 
cases where the home gateway 20 accepts the connection 
and then continues with further authentication, the home 
gateway 20 might subsequently disconnect the client. For 
such scenarios, the disconnection indication back to the 
NAS 27 may also include a reason. 
L2F Protocol Definition 

The layer two forwarding protocol (L2F) used during a 
virtual dial-up session operates as follows. 

The NAS 27 and the home gateway 20 each have software 
that provide a common understanding of the L2F encapsu- 
lation protocol so that SLIP/PPP packets can be successfully 
transmitted and received across the internet 18. The PPP/ 
SLIP packets are encapsulated within L2F. The encapsulated 
packet is the same packet as it would be transmitted over a 
physical link. The entire encapsulated packet includes a L2F 
header, payload packet for SLIP or PPP and an optional 
Checksum. 

FIG. 9 is a detailed diagram showing the data structure of 
the L2F packet. 
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Version Field 

The Ver ("Version") field represents the major version of 
the L2F software creating the L2F packet. 

If any bits are non-zero after bit S, but before bit C, an 
5 implementation must discard the packet and initiate discon- 
nect of the entire tunnel. This would correspond to a packet 
containing extensions not understood by the receiving end. 
Handling of the "Key*' field must be taken in preference to 
this processing, to avoid denial-of-service attacks. Bit P is 
10 used for priority status and bit S is used for sequence 
numbering. 
Protocol Field 

The protocol field ("PROTOCOL") specifies the protocol 
carried within the L2F packet. Legal values (represented 
15 here in hexadecimal) are: 



Value 


Type 


Description 


0x00 


L2F_ILLEGAL 


Illegal 


0x01 


L2F„PROTO 


L2F management packets 


0x02 


L2F_PPP 


PPP tunneled inside L2F 


0x03 


L2F_SLIP 


SLIP tunneled inside L2F 



25 Sequence Number 

The Sequence number starts at 0 for the first L2F packet 
under a tunnel. Each subsequent packet is sent with the next 
increment of the sequence number. The sequence number is, 
thus, a free-running counter represented by modulo 256. For 

30 non-L2F management packets, the sequence number is 
transmitted as 0 and does not increment the local sequence 
counter, and does not affect the processing of received 
traffic. For L2F management packets, the sequence number 
is used to protect against duplication of packets, as follows: 

35 The receiving side of the tunnel records the sequence 
number of each valid L2F packet it receives. If a received 
packet appears to have a value less than or equal to the 
last-received value, the packet must be silently discarded. 
Otherwise, the packet is accepted and the sequence number 

40 in the packet is recorded as the latest value last received. 
For purposes of detecting duplication, a received 
sequence value is considered less than or equal to the 
last-received value if its value lies in the range of the last 
value and its 127 successor values. For example, if the 

45 last-received sequence number is 15, packets with sequence 
numbers 0 through 15, as well as 144 through 255, would be 
considered less than or equal to, and would be silently 
discarded. Otherwise it would be accepted. 
Multiplex ID 

so The Multiplex ID ("MID") identifies a particular connec- 
tion within the tunnel. Each new connection is assigned a 
MID currently unused within the tunnel. The MID cycles 
through the entire 32-bit namespace, to reduce aliasing 
between previous and current sessions. The MID with value 

55 0 is special; it is used to communicate the state of the tunnel 
itself, as distinct from any connection within the tunnel. 
Client ID (CLID) 

The Client ID is used to assist endpoints in demultiplex- 
ing tunnels when the underlying point-to point substrate 

60 lacks an efficient or dependable technique for doing so 
directly. Using CLID, it is possible to demultiplex multiple 
runnels whose packets arrive over the point-to-point media 
interleaved, without requiring media-specific semantics. 
When transmitting a L2F„CONF message (described 

65 below), a peer's CLID must be communicated via an 
assigned__CLID field. This must be a unique non-zero value 
on the sender's side, which is to be expected in all future 
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non-L2F_CONF packets received. The CUD value from 
the last valid L2F_C0NF message received should be 
recorded and used as the CLID field value for all subsequent 
packets sent to the peer. Packets with an unknown CLID are 
silently discarded. 5 

For the initial packet sent during tunnel establishment, 
where no L2F_CONF has yet been received, the CLID field 
is 0. Thus, during L2F_CONF, each side is told its CLID 
value. All later packets sent and tagged with this CLID 
value, serve as a tag which uniquely identifies this peer. 1Q 
Length 

Length is the size in octets of the entire L2F packet, 
including header, all fields present, and payload. Length 
does not reflect the addition of the Checksum, if one is 
present. The L2F packet is silently discarded if the received 
packet is shorter than the indicated length. Additional bytes 15 
presented in the packet beyond the indicated length are 
ignored. 

Packet Checksum 

The Checksum is present if the C bit is present in the 
header flags. It is a 16-bit CRC as used by PPP/HDLC. It is 20 
applied over the entire packet starting with the first byte of 
the L2F flags, through the last byte of the payload data. 
Payload Offset 

The Onset is present if the F bit is set in the header flags. 
This field specifies the number of bytes past the header at 25 
which the payload data is expected to start. If it is 0 or if the 
F bit is not set, the first byte following the last byte of the 
L2F header is the first byte of payload data. 
Packet Key 

The Packet Key is the authentication response last given 30 
to the peer during tunnel creation. It serves as a key during 
the life of a session to resist attacks based on spoofing. If a 
packet is received in which the Key does not match the 
expected value, the packet is silently discarded. 
L2F Tunnel Establishment 35 

When the point-to-point link is first initiated between the 
NAS 27 and the home gateway 20, the endpoints commu- 
nicate on MID 0 prior to providing general L2F services to 
clients. This commununication is used to verify the presence 
of L2F on the remote end, and to permit any needed 40 
authentication. 

The protocol for such negotiation is always 1, indicating 
L2F management. The message itself is structured as a 
sequence of single octets indicating an option, followed by 
zero or more further octets formatted as needed for the 45 
option. 

Normal Tunnel Negotiation Sequence 

The establishment sequence is illustrated by a "typical" 
connection sequence. Detailed description of each function 
follows, along with descriptions of the handling of excep- 50 
tional conditions. 

Each L2F packet is described as a source->destination on 
one fine, a description of the L2F packet field contents on the 
next, and the contents of the packet's body on following 
lines. The exact encoding of octets will be described later. 55 

Note that this example uses the Key option, but does not 
use the Offset and Checksum options. The Length field 
would be present, reflecting the actual length of the packets 
as encoded as an octet stream. 

1. NAS->GW: 60 
Proto=L2F, Seq=0, MID-0, CLID«0, KeyofJ 
L2F__CONF 
Name: NAS_name 
Challenge: RND 
Assigned_CUD: 22 65 
The NAS 27 decides that a tunnel must be initiated from 
the NAS 27 to the home gateway 20 (GW). An L2F packet 
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is sent with the Protocol field indicating that an L2F man- 
agement message is contained. 

Because the tunnel is being initiated, Key is set to 0. The 
sequence number starts at 0; the MID is 0 to reflect the 
establishment of the tunnel itself. Since the NAS 27 has not 
yet received an L2F_CONF, the CLID is set to 0. 

The body of the packet specifies the claimed name of the 
NAS 27, and a challenge random number (RND) which GW 
20 will use in authenticating itself as a valid tunnel endpoint. 
Assigned__CLID is generated to be a value not currently 
assigned out to any other tunnel to any other home gateway. 

2. GW->NAS: 

Proto=L2F, Seq=0, MID=0, CUD-22, Key=C(Rnd) 

L2F_CONF 
Name: GW_name 
Challenge: Rnd2 

Assigned_CLID: 73 
The home gateway 20 has processed the previous packet 
and sends a response. The protocol continues to be L2F, with 
a sequence number 0 (each side maintains its own sequence 
number for transmissions). MID continues to be 0 to reflect 
runnel establishment. CLID reflects the Assigned__CLID 
field of the L2F_CONF received. The Key is a CHAP-style 
hash of the random number received; each packet hereafter 
will reflect this calculated value, which serves as a key for 
the life of the tunnel. 

The body contains the name of home gateway 20 and its 
own random number challenge and its own Assigned_CLID 
for the NAS 27 to place in the CLID field of future packets. 
The CLID is generated in an analogous manner to that of the 
NAS 27. After this, all packets received by GW 20 must be 
tagged with a CLID field containing 73, and all packets sent 
to the NAS 27 must be tagged with a CLID field containing 
22. 

3. NAS->GW 

Proto-L2F, Seq-1, MID-0, CLID-73, Key-C(Rnd2) 
L2F_OPEN 

The NAS 27 responds with its Key now set to reflect the 
shared secret. Like the home gateway 20, the NAS 27 will 
use this Key for the life of the tunnel. 

4. GW->NAS 

Proto=L2F, Seq=l, MID=0, CUD-22, Key«C(Rnd) 
L2F_OPEN 

The home gateway 20 provides closure of the key from 
the NAS 27. The tunnel is now available for clients to be 
established. 

Normal Client Negotiation Sequence 

This section describes the establishment of a virtual 
dial-up client on a NAS 27 into a home gateway 20. It 
assumes a tunnel has been created in the way described 
above. The client for this example is a PPP client configured 
for CHAP. 
1. NAS->GW 
Proto-L2F, Seq=2, MID-1, CUD-73, Key-C(Rnd2) 
L2F__OPEN 
Authen: CHAP 
Client: CHAP-name 
Challenge: Rnd3 

Response:*: Value received, presumably C(Rnd3)> 
The NAS 27 has received a call, tried CHAP with a 
challenge value of Rnd3, and found that the client 
responded. The claimed name leads the NAS 27 to believe 
it was a virtual dial-up client hosted by the home gateway 
20. The next free MID is allocated, and the information 
associated with the CHAP challenge/response is included in 
the connect notification. 
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2. GW->NAS 

Proto«L2F, Seq=2, MID=1, CLID=22, KeyoC(Rad) 
L2F__OPEN The home gateway 20, by sending back 
the L2F_OPEN, accepts the client. 

3. NAS->GW 

Proto=PPP, Seq-O, MID=1, CLID-73, Key=qRnd2) 
<Frame follows> 

4. GW->NAS 

Proto«PPP, Seq=0, MID=1, CUD=22, Key=C(Rnd) 
<Frame follows> 

TraflSc is now free to flow in either direction as sent by the 
remote client 27 or any home site on LAN 22 (FIG. 2). The 
contents of the L2F frames is uninterpreted data such as 
High Level Data Link Control (HDLC). Data traffic, since it 
is not the L2F protocol, does not use the Seq field, which is 
set to 0 in non-L2F messages. 
L2F Management Message Types 

When a L2F packet's Proto field specifies L2F 
management, the body of the packet is encoded as zero or 
more options. An option is a single octet "message type", 
followed by zero or more sub-options. 

Each sub-option is a single byte sub-option value, and 
further bytes as appropriate for the sub-option. 

Options in L2F are: 



Hex Value 


Abbreviation 


Description 


0x00 


Invalid 


Invalid message 


0x01 


L2F_CONF 


Request configuration 


0x01 


L2F_CONF_TYPE 


Type of authentication used 


0x02 


L2F_CONF_NAME 


Name of peer sending L2F_CONF 


0x03 


L2F_CONF_CHAL 


Random # peer challenges with 


0x04 


L2F_CONF_CLID 


Assigned_CLID for peer to use 


0x02 


L2F_OPEN 


Accept configuration 


0x01 


L2F_OPEN_CHAP 


CHAP name received from client 


0x02 


L2F„OPEN_CHAL 


Challenge CHAP client received 


0x03 


L2F_OPEN_RESP 


CHAP challenge response from client 


0x04 


L2F_ACK_LCP1 


LCP CONFACK accepted from client 


0x05 


L2F_ACK_LCP2 


LCP CONFACK sent to client 


0x03 


L2F_CLOSE 


Request disconnect 


0x01 


L2F_CLOSE_WHY 


Reason code for close 


0x02 


L2F_CLOSE_STR 


ASCII string description 


0x04 


l2F_ECHO 


Verify presence of peer 


0x05 


L2F_ECHO_RESP 


Respond to L2F_ECHO 



10 



15 



20 



25 



30 



35 



40 



45 



L2F Message Type: Invalid 

If a message is received with this value, or any value 
higher than the last recognized option value, the packet is 
considered invalid. The packet is discarded, and a L2F__ 
CLOSE of the entire tunnel is requested. Upon receipt of a 
L2F_CLOSE, the tunnel itself may be closed. All other 
received messages are discarded. An implementation may 
also close the tunnel after an interval of time appropriate to 50 
the characteristics of the tunnel. Invalid sub-option values, 
even if present under a valid option, are treated as if the 
entire message type was invalid. 
L2F_CONF 

The L2F message type is used to establish the tunnel 55 
between the NAS 27 and the home gateway 20. MID is 
always set to 0. The body of such a message starts with the 
octet 0x01 (L2F_CONF), followed by one or more sub- 
options. 

The L2F_CONF_TYPE sub-option must be present. It is 
encoded as the octet 0x01, followed by a single byte 
describing the type of authentication the NAS 27 exchanged 
with the remote client 32 in detecting the client's claimed 
identification. The authentication types are: 

0x01 Textual username/password exchange 

0x02 PPP CHAP 

0x03 PPP PAP 



60 



65 



The L2F_CONF_NAME sub-option must be present. It 
is encoded as the octet value 0x02, followed by an octet 
specifying a non-zero length, followed by the indicated 
number of bytes, which are interpreted as the sender's ASCII 
name. 

The L2F_CONF„CIIAL sub-option must be present. It 
is encoded as the octet value 0x03, followed by four bytes 
of challenge value. The challenge value is generated using a 
random number generator. 

The L2F_CONF_CLID sub-option must be present. It is 
encoded as the octet 0x04, followed by four bytes of 
Assigned„CLID value. The Assigned__CLID value is gen- 
erated as a non-zero value unique across all tunnels which 
exist on the sending system. 

The CLID field is sent as 0 when a L2F_CONF packet is 
received from the peer. After this, the Assigned_CLID value 
of the last L2F_CONF packet received must be placed in 
the CLID of all packets being sent. When sent from a NAS 
to a home gateway, the L2F_CONF is the initial packet in 
the conversation. Key is set to 0, since no challenge has been 
received yet. 

When sent from the home gateway 20 to the NAS 27, a 
L2F_CONF indicates the home gateways recognition of the 
tunnel creation request. The home gateway 20 must provide 
its name and its own challenge in the message body. Key 
must be set to the CHAP-style hash of the received challenge 
bytes. 

L2F_0PEN 

The L2F_OPEN message is used to establish a client 
connection within a tunnel previously established by L2F_ 
CONF messages. When sent from the NAS 27 to the home 
gateway 20, it is used to indicate the presence of a new 
dial-up client. When sent back from the home gateway 20 to 
the NAS 27, it indicates acceptance of the client. This 
message starts with the octet 0x02. When sent from the NAS 
27, it may contain further sub-options. When sent from the 
home gateway 20, it may not contain any options. 

The L2F_OPEN_CHAP sub-option is encoded as the 
octet 0x01, followed by an octet specifying the length of the 
CHAP name received, followed by the indicated number of 
bytes of CHAP name. 

The L2F_OPEN_CHAL sub-option is encoded as the 
octet 0x02, followed by an octet specifying the length of the 
CHAP challenge sent, followed by the CHAP challenge 
itself. 

The L2F_OPEN_RESP sub-option is encoded as the 
octet 0x03, followed by an octet specifying the length of the 
CHAP response sent, followed by the client's response to the 
CHAP challenge. This message must be treated as invalid if 
L2F__OPEN_CHAP, L2F_OPEN_CHAL, and L2F_ 
OPEN_RESP do not all appear within the same message. 

The L2F_ACK_LCP1 and L2F_ACK_LCP2 sub- 
options are encoded as the octets 0x04 and 0x05 
respectively, followed in either case by two octets in net- 
work byte order specifying the length of the LCP CON- 
FACK last received from or sent to the client. Following 
these octets is an exact copy of the CONFACK packet. 

The home gateway 20 may choose to ignore any sub- 
option of the L2F__OPEN and accept the connection any- 
way. The home gateway 20 would then have to undertake its 
own LCP negotiations and authentication. 
L2F_CLOSE 

This message is encoded as the byte 0x03. An L2F_ 
CLOSE may be sent by either side of the tunnel at any time. 
When sent with MID of 0, it indicates the desire to terminate 
the entire tunnel and all clients within the runnel. When sent 
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from the home gateway 20 in response to an L2F_OPEN, Because L2F in operation carries uninterpreted frames, it 
it indicates that the home gateway 20 has declined the permits operation of features without explicit knowledge of 
connection. When sent with a non-zero MID, it indicates the these features. For instance, if a PPP session is carried, L2F 
termination of that client within the tunnel. is simply transporting HDLC frames. The two PPP end- 
The L2F_CLOSE_WHY sub-option is encoded as the 5 P oints can negotiate higher-level features, such as reliable 
byte 0x01 foUowed by four bytes in network byte order Hnk > compression, multi-link, or encryption, 
specifying a bit mask of reasons for the disconnection. The These features then operate between the two PPP end- 
bits are encoded as- points (the dial-up client on one end, and the home gateway 
0x00000001 Authentication failed f on the other), with L2F continuing to simply ship HDLC 
^ r^riM*^ ^i- m frames back and forth. For similar reasons, PPP echo 
0x00000002 Out of resources ™ requestSj NCp configuration negotiation, and even termina- 
0x00000004 Administrative intervention tion re quests, are all simply tunneled HDLC frames. 
0x00000008 User quota exceeded Termination 

0x00000010 Protocol error As L2F simply tunnels link-level frames, it does not 

0x00000020 Unknown user 15 detect frames like PPPTERMREQ. L2F termination in these 

0x00000040 Incorrect password scenarios is driven from a protocol endpoint; for instance, if 

0x00000080 PPP configuration incompatible a home gateway 20 receives a TERMREQ, its action will be 

Bits in the mark OxFFOOOOOO are reserved for per-vendor t0 " han & U P" the PPP session - ^ UF implementation at 

interpretation the nome gateway converts a "hang up" into a L2F__CLOSE 

An implementation can choose to not provide status bits 20 aclion > which wil1 shut down the client ' s in the 

even if it detects a condition described by one of these bits. tunnel cleanly. L2F_CLOSE_WHY and L2F__CLOSE_ 

For instance, an implementation may choose to not use STR ma y be included to describe me reason for the shut " 

0x00000020 due to security considerations, as it can be used down, 

to prove user name space. Extended Authentication 

The L2F_CLOSE_STR sub-option is encoded as the 25 is compatible with both PAP and CHAP protocols, 

byte 0x02, followed by a two-byte length in network byte SLIP does QOt P r0Vlde authentication within the protocol 

order, followed by the indicated number of bytes, which are itself > thus K< ^ KS an AS™ exchange of username and 

interpreted as descriptive ASCII text associated with the password before SLIP is started. L2F is compatible with this 

disconnection. This string may be ignored, but could be mode of operation as well. 

recorded in a log to provide detailed or auxiliary information 30 To me extent the NAS 27 can capture and forward the 

associated with the L2F_CLOSE. one-time password, L2F operation is compatible with pass- 

L2F ECHO word c 31 ^- For the most general solution, an arbitrary 

Transmission of L2F_ECHO messages are optional. If an request/response exchange is supported. In a L2F 

implementation transmits UF_ECHO messages, it must environment, the protocol is structured so that the NAS 27 

not transmit more than one such request each second. The 35 can detect me apparent identity of the user and establish a 

payload size must be 64 bytes or less in length. tunnel connection to the home gateway 20, where the 

The L2F_ECHO message is encoded as the single byte arbitrary exchange can occur. 

0x04. It can be sent by either side once the tunnel is ^ home gateway 20 requires authentication before 

established. MID must be 0. An U2F_ECHO„_RESP must accepting a connection from NAS 14. Thus, there will not be 

be sent back in response. 40 a spurious run-up of line toll charges since the remote client 

L2F ECHO RESP does Do1 ^ rs * connect to the private system and then provide 

AH implementations respond to L2F_ECHO, using an appropriate PPP authentication protocol (e.g., CHAP). 

UF_ECHO_RESP. The received packet is sent back It should also be apparent that many of the UF operations 

verbatim, except that the CUD, sequence number, and conducted by NAS 27 could be alternative performed in the 

Checksum (if any) must be updated, and the L2FJCHO 45 remote client 32. For example, the random number 

message type changed to an L2F__ECHO_RESP. Payload generation, encryption and transmission could be conducted 

data following the 0x04 octet, if any, must be preserved in b Y the remote chent without interaction by the NAS 

the response tunneling negotiations and L2F encapsulation could 

When an L2F ECHO RESP is received, the payload similarly be conducted in the remote client instead of the 

" — KT AC 'J'J 

data may be used to associate this response with a previously 50 ~'* 

sent L2F_ECHO, or the packet may be silently discarded. Havm S Ascribed and illustrated the principles of the 

L2F Message Delivery invention in a preferred embodiment thereof, it should be 

L2F is designed to operate over point-to-point unreliable a PP a rent that the invention can be modified in arrangement 

links. It is not designed to provide flow control of the data and deiail without departing from such principles. I claim all 

traffic, nor does it provide reliable delivery of this traffic; 55 modifications and variation coming within the spirit and 

each protocol tunnel via L2F is expected to manage flow ^Pe of toe following claims, 

control and retry itself. Thus, it is only L2F control messages What 15 £ lam 3 ed ^ . 

which must be retransmitted; this process is described in this l - A method for creating a secure dial-up session from a 

section remote client to a local network through an internet service 

Sequenced Delivery 60 P rovider : comprising: 

All L2F control messages (i.e., those L2F packets with a establishing a first communication link between the 
protocol type of 0x01) are transmitted with a sequence remote client and the internet service provider; 
number. The sequence number is a per-L2F tunnel free- sending a random number from the internet service pro- 
running counter which is incremented (modulo 256) after vider to the remote client; 

each packet is transmitted. It is used to permit the receiving 65 encrypting the random number according lo a remote 

end to detect duplicated or out-of-order packets, and to client password to obtain a first keyed random number 

discard such packets. with the remote client; 
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transmitting a remote client name and the first keyed 

random number from the remote client to the internet 

service provider; 
transmitting the remote client name, the random number, 

and the first keyed random number from the internet 5 

service provider to a local network; 
mapping the remote client name with a corresponding 

prestored client password at the local network; 
encrypting the random number according to the prestored iQ 

client password to obtain a second keyed random 

number; 

comparing the first keyed random number with the second 
keyed random number to authenticate the remote client; 
and 35 

establishing a second communication link between the 
internet service provider and the local network when 
the first keyed random number is authenticated with the 
second keyed random number. 

2. A method according to claim 1 including conducting a 2 q 
layer-2 forwarding protocol between the internet service 
provider and the local network that projects the first com- 
munication link from the remote client to the local network. 

3. A method according to claim 1 wherein the remote 
client: 25 

generates the random number; 

encrypts the random number according to the remote 
client password to obtain the first keyed random num- 
ber; and 

transmits the remote client name, the random number, and 30 
the first keyed random number directly to the local 
network. 

4. A method according to claim 1 including encrypting the 
random number according to the remote client password at 
both the remote client and at the local network while the 35 
remote client password remains unknown to the internet 
service provider. 

5. A method for establishing a secure virtual dial-up link 
with a network access server, comprising: 

conducting a point-to-point protocol session with a 40 
remote client; 

identifying when the remote client has a virtual dial-up 
address authorized to access a local network; 

sending a random number to the identified remote client 45 
enabling the remote client to conduct a first encryption 
of the random number according to a remote client 
password; 

forwarding a remote client name, the random number and 
the first encrypted random number to the local network 50 
enabling a second independent encryption of the ran- 
dom number at the local network using a prestored 
password corresponding with the remote client; 

establishing a virtual direct dial-up link from the remote 
client to the local network when the first encrypted 55 
random number matches the second encrypted random 
number. 

6. A method according to claim 5 wherein establishing the 
virtual direct dial-up link comprises encapsulating the point- 
to-point protocol session in an internet protocol and project- 60 
ing the encapsulated point-to-point protocol session through 

a tunnel. 

7. A method according to claim 6 including identifying 
packets transmitted from multiple remote clients having a 
multiplex identification field and attaching headers to the 65 
identified packets for multiplexing the multiple remote cli- 
ents through the same tunnel at the same time. 



8. A method according to claim 7 wherein the header 
includes a client ID field for demultiplexing the multiple 
remote clients in the same tunnel. 

9. A method according to claim 8 wherein the header 
includes a packet key for conducting the second independent 
encryption of the random number at the local network. 

10. A method according to claim 5 including initiating the 
point to point protocol session between the remote client and 
the local network by sending a set-up notification packet to 
the local network, the set-up notification packet having LCP 
parameters for a completed LCP negotiation between the 
remote client and the network access server. 

11. A network access server, comprising: 

a first interface receiving a point-to-point protocol session 

with a remote client; 
a second interface connected to an internet infrastructure 

for transferring information using an internet protocol; 

and 

a processor and memory connected between the first 
interface and the second interface, the processor attach- 
ing forwarding protocol headers to packets transferred 
during the point-to-point protocol session for project- 
ing the point-to-point protocol session through the 
internet infrastructure to a local network independently 
of the internet protocol. 

12. A network access server according to claim 11 
wherein the processor negotiates a tunnel through the inter- 
net infrastructure to the local network and transmits the 
packets having the forwarding protocol headers and the 
point-to-point protocol session over the tunnel. 

13. A network access server according to claim 12 
wherein the tunnel is established independently of a dial-up 
phone number used by the remote client for dialing up the 
network access server. 

14. A network access server according to claim 11 
wherein the forwarding protocol headers include a multiplex 
ID field for multiplexing the packets from different point- 
to-point link sessions in a common tunnel. 

15. A network access server according to claim 14 
wherein the forwarding protocol headers include a client ID 
field for identifying and demultiplexing the packets in the 
common tunnel at the local network. 

16. A network access server according to claim 11 
wherein the forwarding protocol headers include a packet 
key field for authenticating the packets. 

17. A network access server according to claim 11 
wherein the forwarding protocol headers include the follow- 
ing: 

a client name; 

a random number challenge; and 
a management message for communicating the status of 
the transported point-to-point protocol session. 

18. A gateway for securing a dial-up session between a 
remote client and a local network, comprising: 

a first interface connected to the remote client for receiv- 
ing a remote client name, a random number and a first 
encrypted random number; 
a second interface connected to the local network; and 
a processor and memory connected between the first and 
second interface independently generating a second 
encrypted random number according to a prestored 
password in the memory corresponding with the remote 
client name, the processor establishing a virtual direct 
dial-up link between the remote client and the local 
network when the second encrypted random number 
matches the first encrypted random number. 
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19. A gateway according to claim 18 wherein the virtual 
direct dial-up link includes conducting a layer-2 forwarding 
protocol that projects a point-to-point link from the remote 
client to the local network. 

20. A gateway according to claim 19 wherein the layer-2 
forwarding protocol includes establishing a tunnel connec- 
tion between the remote client and the local network. 
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21. A gateway according to claim 18 wherein a slot in the 
tunnel assigned to the remote client is disconnected by the 
processor if the remote client name is not prestored in the 
memory or the second random number does not match the 
first random number. 
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